Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-02

Text File | 1995-12-31 | 99KB | 2,808 lines

Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Problems with one CDEV/INIT appearing twice on startup
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 2 Feb 91 14:53:27 GMT

I was trying to do the Code resources/CDEV example from the Macintosh
Programming Primer vol. II (by Dave Mark, Addison Wesley 1990). I have
gotten it to work, but when the INIT loads, it the icon shows up twice
along the lower boundary. The code for icon display is (essentially)
ShowINIT by Paul Mercier.
My question is: what makes the Finder or Mac startup recognize that
there is an INIT that must be loaded? What would make it think that
there are two of this thing?
Any help appreciated.

Cheers,
David S. McCormick
MIT-EAPS Geology
Bldg. 54-1016
Cambridge, MA 02139
617-253-9852
[e-mail]
CompuServe: 71540,2765
Disclaimer: Grad students are, for all intents and purposes, unemployed,
and therefore don't need disclaimers.










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Another problems with one CDEV/INIT
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 2 Feb 91 15:28:45 GMT

I rooted around with ResEdit and found that the I had 2 INIT resources
in my CDEV. I pasted a single INIT resource into the cdev.9.rsrc file
with ID=0. After choosing Build Code Resource... the final code resource
had two, nearly identical INIT resources, one of ID=0 and one of ID=128.
Why did the compiler create another INIT resource? Would this have been
prevented if I had pasted in the INIT resource after compiling? Should I
have changed the INIT resource's ID? As you can tell, code resources are
totally foreign to me.
Thanks again.
Cheers,
David S. McCormick
MIT-EAPS Geology
Bldg. 54-1016
Cambridge, MA 02139
617-253-9852
[e-mail]
CompuServe: 71540,2765
Disclaimer: Grad students are, for all intents and purposes, unemployed,
and therefore don't need disclaimers.










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: 1: How do you implement CTask subclass? 2: Is it better to Close a file immediately after Open-Read
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 3 Feb 91 18:04:44 GMT

(1) I would like any suggestions about how to implement the subclasses
of CTask. Specifically:

What info needs to be stored in a task?
Where in the application does MyTask get invoked? What do you send with
the message?
What is the CTask::Do() method? How does it differ from the Undo/Redo?

(2) Is it better form or safer to Close() a file immediately after
Opening and Reading contents?

Thanks for any suggestions.

Cheers,
David S. McCormick
MIT-EAPS Geology
Bldg. 54-1016
Cambridge, MA 02139
617-253-9852
[e-mail]
CompuServe: 71540,2765
Disclaimer: Grad students are, for all intents and purposes, unemployed,
and therefore don't need disclaimers.










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: 020/881
Message-ID: <9102041711.AA05863@neuromancer>
Newsgroups: fa.think-c
Lines: 43
Date: 4 Feb 91 19:34:41 GMT

I'm trying to maintain two versions of some calc-intensive code under ThC.

Is there any way to know within the code whether it's being compiled with either
the 68020 and/or 68881 options?

For example, it would be great to use a source file that does:

    #ifdef MC68020
    #asm MC68020 {
        /* assembly optimizations that scream through

            tight loops on a Mac II class machine
         */
    }
    #else
    #asm MC68000 {
        /* assembly optimizations that run faster than
            ThC code, but still work on Classics,etc.
         */
    }
    #endif

The code needs to be inline, as opposed to a separate library, and it would

be a lot easier to maintain "n" source files instead of "2n" files.  Even an explicit
"ifdef" in one of the header files would be nasty in this project....  And speaking
as a former compiler-writer, MOST COMPILERS AUTOMATICALLY GENERATE
DEFINES FOR THEIR OPTIONS...

Thanks, and happy hacking!

-paco
----
Internet:    [e-mail]
AppleLink:    Nathan2
Voice Mail:    1.512.891.2973

Neural Networks & Virtual Reality Development
Center for Emerging Computer Technologies
Motorola, Inc.
Austin, Texas, USA

(c)1990, PXN. Subject to Public Law 99-508.  B*B!










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Trouble using TextFont() in Panorama
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 5 Feb 91 07:54:34 GMT

I am using a hierarchical font menu in conjunction with a panorama and I
am having trouble getting the font displayed in my panorama panorama to
match the menu selection. I borrowed the fontItem instance variable from
CEditText along with the DoCommand() and UpdateMenus() fragments which
have to do with the Font menu. The instance variable gets changed
correctly if I select the font menu. I set the default of the instance
variable to monaco. My quickdraw calls are done into picture, and just
before I need to draw the text I call TextFont( fontItem ). What I get
the first time through, before I change anything, is the font as monaco.
If I choose a new font, the font changes to geneva (applFont), but never
changes after that. What am I missing? Do I have to call TextFont()
before Prepare()? Do I have to call TextFont() before OpenPicture()? Any
help appreciated.

Cheers,
David S. McCormick
MIT-EAPS Geology
Bldg. 54-1016
Cambridge, MA 02139
617-253-9852
[e-mail]
CompuServe: 71540,2765










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: 020/881
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 5 Feb 91 11:33:08 GMT

>For example, it would be great to use a source file that does:
>
>    #ifdef MC68020
>    #asm MC68020 {
>        /* assembly optimizations that scream through
>
>            tight loops on a Mac II class machine
>         */
>    }
>    #else
>    #asm MC68000 {
>        /* assembly optimizations that run faster than
>            ThC code, but still work on Classics,etc.
>         */
>    }
>    #endif

My feeling is that this is rather Macintosh-unfriendly, as you end up with
two versions of your application, one for each kind of machine. Better to
ask the Mac what processor it has (via SysEnvirons, Gestalt, whatever) and
switch to the correct portion of code. That way you have one application
that can run on anything.

Well, it's just a thought.

Nick.











Path: ucivax!gateway
From: [e-mail] (Greg Stein)
Subject: Re: 020/881
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 47
Date: 5 Feb 91 15:34:38 GMT

You can always package your processor-specific code into a code
resource and dynamically load/link it into your program based on
Gestalt.  This would provide you the benefit that both versions of the
program do not have to be in memory simultaneously.

Dynamically loading code resources is not that difficult to do, once
you get the hang of it.


Greg Stein
Arpa: [e-mail]
UUCP: ..!{uunet,apple}!oracle!gstein


---- Included Message ----
From: Nick Rothwell <[e-mail]>
Newsgroups: fa.think-c
Date: 5 Feb 91 11:33:08 GMT

>For example, it would be great to use a source file that does:
>
>    #ifdef MC68020
>    #asm MC68020 {
>        /* assembly optimizations that scream through
>
>            tight loops on a Mac II class machine
>         */
>    }
>    #else
>    #asm MC68000 {
>        /* assembly optimizations that run faster than
>            ThC code, but still work on Classics,etc.
>         */
>    }
>    #endif

My feeling is that this is rather Macintosh-unfriendly, as you end up with
two versions of your application, one for each kind of machine. Better to
ask the Mac what processor it has (via SysEnvirons, Gestalt, whatever) and
switch to the correct portion of code. That way you have one application
that can run on anything.

Well, it's just a thought.

Nick.












Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Disabling Hier Menu (was: Trouble using TextFont() in Panorama)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 5 Feb 91 15:59:52 GMT

OK, so I was tired at 2AM and didn't read CEditText closely enough. I
found out that a call to LoShort(-theCommand) extracts the _item number_
of the menu item, not the _font number_.... I've fixed it to correctly
set both the font item number and get the correct text.

I have a new problem (what a surprise): How do you disable a
hierarchical menu name in the menu to which it's attached. I have a menu
called "Plot" to which is attached the "Font" hierarchical menu. I used

gBartender->DisableMenu( MENUfont )

but this has 2 undesirable (or incomplete) side-effects: (1) there is
some nasty menu bar flicker whenever I call DisableMenu(), so I try to
just use DisableCmd() wherever possible (I have are several edit text
fields that each to refresh the menu bar). (2) This is the real problem:
Although, all the Font menu items are disabled, I cannot disable the
"Font" menu text in the "Plot" menu; whenever I try to do this by
extracting item numbers and converting them to command numbers, the
command number points to the hierarchical menu (MENUid), not the Plot
menu. Am I missing something? Is there a way to disable the label (and
forego using DisableMenu() )? [As a side question, can you even do this
with a straight Toolbox call?]

Thanks in advance.

Cheers,
David S. McCormick
MIT-EAPS Geology
Bldg. 54-1016
Cambridge, MA 02139
617-253-9852
[e-mail]
CompuServe: 71540,2765










Path: ucivax!gateway
From: [e-mail] (Peter Miller)
Subject: Re: 020/881
Message-ID: <9102052207.AA04071@elm>
Newsgroups: fa.think-c
Lines: 26
Date: 6 Feb 91 02:01:20 GMT


> Better to
> ask the Mac what processor it has (via SysEnvirons, Gestalt, whatever) and
> switch to the correct portion of code. That way you have one application
> that can run on anything.

This is one of my gripes with the Mac.

Has anyone done a 68881 emulator INIT?
I.e. trap 68881 opcodes and emulate them in software, in the absence of
a 68881.  [This is what my 68000 books says the F-line traps are for.]
That way, I could drop the init into my system folder on any machine
without a 68881, and it would behave as if it did (if the INIT was smart
it would check if a real 68881 was there, and do nothing if so).
Then, all code can assume a 68881, and we don't wind up with
two versions of all floating-point applications.

Regards
Peter Miller    UUCP    uunet!munnari!pdact.pd.necisa.oz!pmiller
        ACSnet    [e-mail]
/\/\*        CSNET    [e-mail]
Disclaimer:  The views expressed here are personal and do not necessarily
    reflect the view of my employer or the views or my colleagues.

"I have discovered that in this business you need animators,
accountants and bookkeepers can't do it." - Walt Disney.










Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  04-Feb-1991 1512")
Subject: re: CTask subclass
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 131
Date: 6 Feb 91 03:00:57 GMT

Funny, I did that last night.  Took about an hour, most of which was
spent mumbling to myself and wiping tears off the manual.  Most of the
code will transport to your application without trouble.  I suspect that
I might update SplitsDoc::SetSomeValue so it has a non-undoable entry
point (for reasons unrelated to this example).

Hope this helps.

Martin Minow.
[e-mail]

/*
 * ValueTask header.
 */
#define _H_ValueTask
#include <CTask.h>
#include "SplitsDoc.h"

struct ValueTask : CTask {
    short        itsClass;
    short        itsDistance;
    double        itsElapsed;
    CharsHandle    itsLeader;

    void        IValueTask(
        SplitsDoc    *aSplitsDoc
    );
    void    Dispose(void);
    void    Undo(void);
};

/*
 * ValueTask.c
 */
#include "ValueTask.h"
#include "SplitsDoc.h"

/*
 * This is called (by the OK button) just before I store some
 * data away.  SplitsDoc is the "document" class.
 */
void
ValueTask::IValueTask(
    SplitsDoc    *aSplitsDoc
    )
{
    /*
     * I store stuff in a ValueList (list of values).
     * One of the things I store is a CharsHandle
     * that originates in a CEditPane.  Note the
     * way HandToHand is called.
     */
    ValueList        *aValueList;
    CharsHandle        currentLeader;
    OSErr            status;

    inherited::ITask(UNDO_NewValue);
    aValueList = aSplitsDoc->itsValueList;
    itsClass = aSplitsDoc->itsClassIndex;
    itsDistance = aValueList->GetSelection();
    itsElapsed = aValueList->GetElapsed(itsDistance);
    /*
     * Duplicate the leader (stored in a CEditPane instance).
     */
    currentLeader = aSplitsDoc->CurrentLeader();
    status = HandToHand(¤tLeader);
    gError->CheckOSError(status);
    itsLeader = currentLeader;
}

void
ValueTask::Dispose()
{
    if (itsLeader != NULL)
        DisposHandle((Handle) itsLeader);
    inherited::Dispose();
}

/*
 * TCL calls this upon Undo.
 */
void
ValueTask::Undo()
{
    SplitsDoc    *aSplitsDoc;
    SplitsDocList    *theDocList;
    ValueList    *theValueList;
    ValueItem    *theValue;

    theDocList = gApplication->raceClasses;
    aSplitsDoc = theDocList->GetSplitsDoc(itsClass);
    if (aSplitsDoc != NULL) {
        /*
         * Store the value and update the data entry dialog.
         */
        aSplitsDoc->SetSomeValue(itsDistance, itsElapsed, itsLeader);
        aSplitsDoc->PutSelectedSplitInDialog();
    }
}

/*
 * This is the SplitsDoc method that stores data in the value list.
 */
void
SplitsDoc::SetSomeValue(
    short        aDistance,    /* Distance we're changing    */
    double        anElapsed,    /* Time at this distance    */
    CharsHandle    aLeader        /* Who is leading the race    */
    )
{
    ValueTask    *aValueTask;
    ValueItem    *theValue;

    /*
     * Save enough information to Undo the action.
     */
    aValueTask = new(ValueTask);
    aValueTask->IValueTask(this);
    /*
     * Next, store the new data.
     */
    theValue = itsValueList->GetItem(aDistance);
    theValue->StoreSplit(anElapsed, aLeader);
    itsValueList->ChangeSelection(aDistance);
    /*
     * Inform the document and TCL
     */
    dirty = TRUE;
    Notify(aValueTask);
}











Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: 020/881
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 6 Feb 91 04:18:52 GMT


[Peter expresses a desire for a 68881 emulator INIT in order to avoid having
to ship two versions of software for FPU vs non-FPU systems.]

Emulators are not a cure-all. First of all, an emulator will be far slower
on a machine than SANE is, which misses the whole point of having an
emulator (i.e. better floating-point performance). Second, an emulator
will be huge, since it has to emulate ALL of the possible opcodes and
addressing modes that may be generated, including some of the el-wierdo
68020-type "base address register with index and outer displacement and
memory indirect" modes, which are truly horrendous.

If you don't want to have two projects which differ only in compiler settings,
and possibly only in a few utility routines which have been rewritten
in 881 assembly language, then supply your users with a SANE-compiled
version. SANE uses the FPU if it's there, and many third-party companies
(Radius and Daystar come to mind) have INITs which route SANE calls to
the built-in FPU. Also, SANE is more accurate in some cases.

-- which reminds me of a third gotcha: with an emulator, you're at the mercy
of whoever wrote it, so if it's got bugs or inaccuracies, you're going to have
a million calls of "Why doesn't it work on my IIsi without an FPU?", when
you're testing your brains out and it works perfectly on your Mac II.

Who says "real men don't do floating point"? :-)

R.

 Rich Siegel    Symantec Languages Group  Internet: [e-mail]

"I was just trying to be subtle. That's my job, isn't it?"










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: 020/881
Message-ID: <[e-mail]>
In-Reply-To: Peter Miller's message of 06 Feb 91 02:01:20 +0000.
             <9102052207.AA04071@elm>
Newsgroups: fa.think-c
Lines: 31
Date: 6 Feb 91 05:20:55 GMT


Peter writes:

> Has anyone done a 68881 emulator INIT?
> I.e. trap 68881 opcodes and emulate them in software, in the absence of
> a 68881.  [This is what my 68000 books says the F-line traps are for.]
> That way, I could drop the init into my system folder on any machine
> without a 68881, and it would behave as if it did (if the INIT was smart
> it would check if a real 68881 was there, and do nothing if so).
> Then, all code can assume a 68881, and we don't wind up with
> two versions of all floating-point applications.

Those of us that have IIsi's are grateful for an INIT called PseudoFPU
(available from your favorite archive), which traps the FPU
instructions and calls SANE -- not speedy, but it works, and allows us
to run programs that assume that anything with a 68030 also has an
FPU.  I believe it disables itself if an FPU is really present; it
also disables itself in the presence of Excel and DataDesk, which will
use their own floating point routines if there is no FPU (and so run
faster -- PseudoFPU is supposed to be *100 times slower* than an FPU).

Truly portable Macintosh applications are supposed to use SANE for
their floating point arithmetic, since it's (1) always present and (2)
more accurate than the 881/882.  (SANE on a machine with an FPU uses
the FPU; otherwise it's all done in software.)  However, Apple
recognizes that using the FPU directly is faster than calling SANE (at
least, it does as of the second edition of the "Apple Numerics
Manual"); it's mentioned as a speed/portability tradeoff.

-- Russell S. Finn
rsfinn@{athena,lcs}.mit.edu










Path: ucivax!gateway
From: [e-mail]
Subject: Re: 020/881
Original-From: attmail!pegasus!ech (Ned Horvath )
Lines: 38
Date: 6 Feb 91 19:21:47 GMT
Message-Service: mail
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0370730130> of Wed Feb 6 05:20:55 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: Text
Content-Length: 2043
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ech-817>
UA-Content-ID: <PMX-PC-2.01A-000146-pegasus3-ech-1038>
MTS-Message-ID: <pegasus0371624040>

------------ Original Message -------------
...
Truly portable Macintosh applications are supposed to use SANE for
their floating point arithmetic, since it's (1) always present and (2)
more accurate than the 881/882.  (SANE on a machine with an FPU uses
the FPU; otherwise it's all done in software.)  However, Apple
recognizes that using the FPU directly is faster than calling SANE (at
least, it does as of the second edition of the "Apple Numerics
Manual"); it's mentioned as a speed/portability tradeoff.

-- Russell S. Finn
rsfinn@{athena,lcs}.mit.edu
--------- End of Original Message ---------

The tradeoff is quite large: when I worked for Manx (Aztec C) we implemented
direct-F-line instructions for floating point as an option.  With that option,
the 68881 is about 400 times faster than "raw" SANE, and about 20 times faster
than letting SANE call the '881.  This isn't surprising -- inline code avoids
a subroutine call and the test for FPU present.

The tradeoff is the accuracy mentioned and the requirement that you have a
"FPU only" version of your application, or follow one of the other
recommendations (keep the FP in a separately compiled "PACKage" and install
the one that fits when you start up).  But that factor of 20 can make a BIG
difference when the application is FP intensive.

OK, on the soapbox: Floating Point is for quick knockoffs and programmers with
weak minds: you (almost) always can do a given job using much less expensive
fixed-point arithmetic: use integers, but with the binary point somewhere
other than the extreme right.  T'ain't hard, but fixed point does require that
you understand the problem domain well, and that the "domain of discourse" is
only a few orders of magnitude in size, but that describes almost all problems
where FP is used.  A couple of good commercial examples are MacSwivel and
MacSpin, neither of which use floating point to do some pretty magical things,
and they run with good pace even on a Mac Plus.  Standing down from soapbox...

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: re: 020/881
Message-ID: <9102062015.AA06569@neuromancer>
Newsgroups: fa.think-c
Lines: 32
Date: 6 Feb 91 22:08:27 GMT

Thanks for all the advice on detecting compiler options.


I understand the Gestalt/SysEnvirons argument and in 99% of my applications, especially
the commercial releases, I would agree.


BUT, inside a critical, tight loop where one would typically use inline assembly, making a
call out to another code resource, another routine is the wrong approach.  So some kind of
"ifdef" seems the best way to maintain both 020/881 & 000 compatible code.  I just run two
separate projects off the same source code and generate two separate applications.  Of
course, some kind of change administration built into ThC projects would be even better....

I'd also argue about the size of the Mac software development market that is targeted for
"proof of concept".  The politically correct Mac "guidelines" aim for the shrink-wrap market
and semi-naive users.  Great, yup 99% of the time.  On the other hand, I'd say that a large
bulk of $$ going into Mac software development is for demonstration purposes, "proof of
concept", being able to rapidly prototype and demo a business opportunity in front of a
vice president, an academic dean, etc.  I'm curious whether other folks who earn their
keep off the Mac would agree.

pacoid.
----
Internet:    [e-mail]
AppleLink:    Nathan2
Voice Mail:    1.512.891.2973

Neural Networks & Virtual Reality Development
Center for Emerging Computer Technologies, Motorola, Inc.
Austin, Texas, USA

(c)1990, PXN. Subject to Public Law 99-508.  B*B!










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: MacsBug's Bugs
Message-ID: <9102062020.AA06575@neuromancer>
Newsgroups: fa.think-c
Lines: 18
Date: 6 Feb 91 22:08:48 GMT

Okay, here's a weird one.  I take a well-working Mac II, have NYNEX upgrade it to a IIfx,
then run 6.0.7 with no extraneous INIT's or CDEV's, except for MacsBug 6.1 straight out of
the shrink-wrap from APDA

But when I hit the programmer switch, MacsBug comes up and promptly hangs.  I get an
NMI and the command line editor cursor blinks, but it won't except any input from the
keyboard.

I've checked in with Apple, but so far nobody's seen this before.  Sound like just a bad
logic board upgrade?

pacoid.
----
Internet:    [e-mail]
AppleLink:    Nathan2
Voice Mail:    1.512.891.2973

(c)1990, PXN. Subject to Public Law 99-508.  B*B!










Path: ucivax!gateway
From: autodesk!ceili![e-mail] (Robert Murphy)
Subject: Re: 020/881
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 66
Date: 6 Feb 91 22:35:08 GMT

Ned Horvath writes:

>The tradeoff is quite large: when I worked for Manx (Aztec C) we implemented
>direct-F-line instructions for floating point as an option.  With that option,
>the 68881 is about 400 times faster than "raw" SANE, and about 20 times faster
>than letting SANE call the '881.  This isn't surprising -- inline code avoids
>a subroutine call and the test for FPU present.

These statements are quite true.  Back in the dim dark ages (pre-Mac II),
when the only 020/881 option was the Levco Prodigy, I was one of the
programmers on a commercial product named Trapeze, and was the numerics
guy.  As an example of the speed tradeoffs, I found at the time that doing
a particular matrix inversion required about several minutes using SANE on
a 16 MHz 68020; in those days (1986), SANE didn't know about FPUs yet.
When I simply replaced my adds, multiplies and divides with function calls
to inline assembly which used the FPU, the inversion went to five seconds.
Later, just for fun, I hand-tweaked the entire matrix inversion routine
in 020/881 assembly, and got it down to 1/2 second.

>The tradeoff is the accuracy mentioned and the requirement that you have a
>"FPU only" version of your application, or follow one of the other
>recommendations (keep the FP in a separately compiled "PACKage" and install
>the one that fits when you start up).  But that factor of 20 can make a BIG
>difference when the application is FP intensive.

I've found the accuracy tradeoff to be a complete non-issue.  The 881
and SANE give you exactly the same results, down to the last bit, for
fundamental operations (add, subtract, multiply, divide, etc.)  You
only notice a difference when using transcendentals with the extended
(80-bit) floating point type, and the biggest difference I ever noted for
a single operation was in the least significant bit of the 64-bit
mantissa - big hairy deal.  Of course, this kind of error can accumulate
if you're doing long, complicated sets of operations like calculating
eigenvectors of large matrices - but numerical instability due to accumulated
roundoff is part of life in the world of numerical analysis, as any textbook
on the subject will tell you, and even SANE is not immune to the problem;
it just falls apart when you use a 51x51 matrix instead of the 50x50
you get with the FPU.  I daresay that either one is a hell of a lot better
when you use 80-bit reals than what you'd get with the 64-bit reals you
get stuck with in the Intel world.

>OK, on the soapbox: Floating Point is for quick knockoffs and programmers with
>weak minds: you (almost) always can do a given job using much less expensive
>fixed-point arithmetic: use integers, but with the binary point somewhere
>other than the extreme right.  T'ain't hard, but fixed point does require that
>you understand the problem domain well, and that the "domain of discourse" is
>only a few orders of magnitude in size, but that describes almost all problems
>where FP is used.  A couple of good commercial examples are MacSwivel and
>MacSpin, neither of which use floating point to do some pretty magical things,
>and they run with good pace even on a Mac Plus.  Standing down from soapbox...

I disagree completely.  There is some truth in what Ned says about when
you might be able to apply fixed point math, but he is just flat wrong
when he says that such situations encompass "almost all problems where
FP is used".  You can begin by removing from "almost all problems" a
huge chunk of CAD, especially 3-D, and also much of scientific computing.
I work in both problem domains, and I don't use floating point because
I'm lazy or stupid - I use them because nothing else would work.

>=Ned Horvath=
>[e-mail]
>

Bob Murphy
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Peter Miller)
Subject: Re: 020/881
X-Face: u\%{\QY_5[S37dfQ#c*#""=K,KGq>4wGryNm+=TT]1jOGap~>j*-sb9d|ll.sHIJu&n{:T`
 cP|e(B?o,W%l_)o5pW,"MVie?sw{hZ@7E^o`C:wz){1p!u%O<N#lcPP]b|f:2,-mNKt{Ue(_7e"ok@
 b".~TQ#YGrlY[r!:5q[/"O&Bn4:3mwuUFt>Qc]KTq}A")Jk,[
Message-ID: <9102070112.AA05159@elm>
In-Reply-To: Your message of Tue, 05 Feb 91 23:14:21 -0500.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 81
Date: 7 Feb 91 03:19:59 GMT


I got a bigger response with this than I expected.
Thanks, everyone who responded.
I wasn't a clear as I could have been, though.

[e-mail] (Rich Siegel) writes:
>
> [Peter expresses a desire for a 68881 emulator INIT in order to avoid having
> to ship two versions of software for FPU vs non-FPU systems.]
>
> Emulators are not a cure-all. First of all, an emulator will be far slower
> on a machine than SANE is,
Hmm, I don't understand this.
Don't they have to do a similar amount of work?
In fact, since SANE is more accurate, wouldn't the emulator be faster,
because it has less to do?

> which misses the whole point of having an
> emulator (i.e. better floating-point performance).
I don't want the emulator for better floating point performance
than SANE gives me, I want it instead of SANE.

> Second, an emulator will be huge,
Hmm, I don't understand this, either.
Don't they do a similar amount of work?
In fact, since SANE is more accurate, wouldn't the emulator be smaller,
because it has less to do?

> since it has to emulate ALL of the possible opcodes and
> addressing modes that may be generated, including some of the el-wierdo
> 68020-type "base address register with index and outer displacement and
> memory indirect" modes, which are truly horrendous.
I have a feeling, having implemented emulators of various chips
(no FPUs, I admit), that addressing modes are trivial when compared with the
compexity of the actual floating-point emulation.

> If you don't want to have two projects which differ only in compiler
> settings, and possibly only in a few utility routines which have been
> rewritten in 881 assembly language, then supply your users with a
> SANE-compiled version.  SANE uses the FPU if it's there,
As another poster pointed out, this is still a 20x performance hit
vs using the FPU direct.

> and many third-party companies (Radius and Daystar come to mind) have INITs
> which route SANE calls to the built-in FPU.
Eh?  Doesn't SANE do this?  (OK, maybe with some niggling value added.)

> Also, SANE is more accurate in some cases.
Claims of additional accuracy don't win me,
because when I can get mucho-speed for niggling-accuracy (20 times faster,
vs. 2^-55 increase in accuracy of answers) I will use direct 68881 opcodes
every time.

> -- which reminds me of a third gotcha: with an emulator, you're at the mercy
> of whoever wrote it, so if it's got bugs or inaccuracies, you're going to
> have a million calls of "Why doesn't it work on my IIsi without an FPU?",
> when you're testing your brains out and it works perfectly on your Mac II.
Hardware has bugs, too.


Perhapse I could have asked the question
    "Why didn't apple do an FPU emulator, rather than SANE?"
    (given that the wins, from my point of view, are small or negative)
and
    "Given that I think apple got it wrong, where can I get an emulator?"
And, yes, I have FTP'd PseudoFPU, will try it shortly.

The other thing is that the emulator would not have needed to be loaded
at boot time, of the hardware was there (if apple had done an emulator,
rather than SANE).  As it is I get SANE and the FPU,
and I don't use SANE (on machines with FPUs).

Regards
Peter Miller    UUCP    uunet!munnari!pdact.pd.necisa.oz!pmiller
        ACSnet    [e-mail]
/\/\*        CSNET    [e-mail]
Disclaimer:  The views expressed here are personal and do not necessarily
    reflect the view of my employer or the views or my colleagues.

"I have discovered that in this business you need animators,
accountants and bookkeepers can't do it." - Walt Disney.










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: 020/881
Message-ID: <[e-mail]>
In-Reply-To: Peter Miller's message of 07 Feb 91 03:19:59 +0000.
             <9102070112.AA05159@elm>
Newsgroups: fa.think-c
Lines: 14
Date: 7 Feb 91 06:09:01 GMT

Peter writes:
>Perhaps I could have asked the question
>    "Why didn't apple do an FPU emulator, rather than SANE?"

Because SANE was invented before machines with 68020/68881 (in fact,
it predates the Macintosh).  I don't think it was known at the time
how the FPU interface would be defined (using F-line traps which have
always been "reserved to Motorola").  I agree it would have been nice
if it could have used the same interface, but it's too late now...

Disclaimer:  I was but a wee lad at the time myself...

-- Russ
rsfinn@{athena,lcs}.mit.edu










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: QuickDraw Gotcha: Never send a FrameArc to do a FrameOval's job
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 29
Date: 7 Feb 91 19:34:37 GMT

This may seem stupid, but I was banging my head on this one for a week
or so. I wrote earlier asking for I was having problems with writing
into a PicHandle which included a call to FrameArc(). I was trying to
make a circle with FrameArc() and it appeared in my scrolling window
just fine, but did not appear when I saved the Picture to a CPictFile
and opened it in Canvas. The call I used was:

FrameArc( &thePictRect, 0, 360);

As I was calling Symantec Tech Support, it finally dawned on me:
FrameArc() computes the arc *MODULUS 360* so that effectively QuickDraw
thinks I'm saying

FrameArc( &thePictRect, 0, 0);

and therefore Canvas saw nothing. I still don't understand why the arc
appeared in my scrolling window in the first place. The bottom line is
that if you use the pathologic case above, you will get nothing in your
Pict file. Instead use

FrameOval( &thePictRect );

and away goes trouble, down the drain.
Never send a FrameArc to do a FrameOval's job.

Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: 020/881
Original-From: attmail!pegasus!ech (Ned Horvath )
Lines: 41
Date: 7 Feb 91 20:05:59 GMT
Message-Service: mail
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0380140410> of Wed Feb 6 22:35:08 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: Text
Content-Length: 2383
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ech-822>
UA-Content-ID: <PMX-PC-2.01A-000146-pegasus3-ech-1045>
MTS-Message-ID: <pegasus0381509510>

I had written:
OK, on the soapbox: Floating Point is for quick knockoffs and programmers with
weak minds: you (almost) always can do a given job using much less expensive
fixed-point arithmetic: use integers, but with the binary point somewhere
other than the extreme right.  T'ain't hard, but fixed point does require that
you understand the problem domain well, and that the "domain of discourse" is
only a few orders of magnitude in size, but that describes almost all problems
where FP is used.  A couple of good commercial examples are MacSwivel and
MacSpin, neither of which use floating point to do some pretty magical things,
and they run with good pace even on a Mac Plus.  Standing down from soapbox...

Bob Murphy ([e-mail]) replied:
I disagree completely.  There is some truth in what Ned says about when
you might be able to apply fixed point math, but he is just flat wrong
when he says that such situations encompass "almost all problems where
FP is used".  You can begin by removing from "almost all problems" a
huge chunk of CAD, especially 3-D, and also much of scientific computing.
I work in both problem domains, and I don't use floating point because
I'm lazy or stupid - I use them because nothing else would work.
--------- End of Original Message ---------

Thanks for the followup, Bob, no insult intended.  My caveat included "only a
few orders of magnitude" in the problem domain, and I'll certainly concede
that there are cases where very large and very small numbers get mixed up.
An example: the nature of a semiconductor is determined by p-type or n-type
impurities which comprise on the order of 1E-8 of the sample.  There are too
many orders of magnitude between the largest and smallest numbers for fixed
point to be effective.  Playing with fractals is another -- one sets the
"fractalscope" on many different orders of resolution, and floating point is
the right way to go.

I also mentioned knock-offs.  When you need an answer in a hurry, floating
point allows you to avoid (to some extent) acquiring an intimate knowledge of
the problem space.

But at least consider fixed point for the cases in between.  EVERY 680x0 (and
every whatzit86, for that matter) "knows" how to do fixed point arithmetic
efficiently and without extra coprocessors.  For production programs where
it's applicable, it's an elegant way to go.

=Ned Horvath=










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: re: MacsBug's Bugs & TCL
Message-ID: <9102072159.AA06955@neuromancer>
Newsgroups: fa.think-c
Lines: 15
Date: 8 Feb 91 18:08:35 GMT

followup:  I just found MacsBug 6.2b3 on AppleLink last night.


Runs great on a IIfx.  Nice new features for debugging objects, but they appear to be for

C++ & Object Pascal, not TCL, unless I'm mistaken.  I know they wrote the original
MacsBug downstairs in my building, but the Moto source is a bit out of date :-)

Has anybody here worked on a TCL-specific monitor?

I regret that the MacsBug problem wasn't quite related to this forum, but it did make
debugging a stack problem in a ThC application rather unbearable.

By the way, does anybody here have a copy of the Monkey desk accessory?  I've
misplaced it...










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: re: 020/881
Message-ID: <9102072148.AA06948@neuromancer>
Newsgroups: fa.think-c
Lines: 71
Next-Attachment: .tar.939.re__020_881.attach, 4222, 1/1, 5808, 0
Date: 8 Feb 91 18:08:55 GMT

begin 0 .tar.939.re__020_881.attach
M'YV0:=R0*8/'A1PZ9@`H7,BPH<.'$"-*G$BQ(HB+-FC0``'@XD49-3AZ!!%#
MALB1%VG8F'$CY8T:-&;0@%G#AL<:-V;4Z%BQI\^?0(,*'4JTJ-&C2),J7;IT
M#Y>#9F!P">-F3AJG9MZXH4-'#!LN4<'.N9-FSAP02,JPL5.&3IHQ87;T4<"E
M31@Y9]B4A$'7+EXY>Q5@E6IFC@P:8--(9:.82YRO9^2$R0,#1)TZ;MJ&4/-&
MC-8R+IJT#0,'S1LY+H8\:1*B3)LS(%`T2;.F#(@C<LJ4<1/F3A@V=%*`N",G
M#9TR<W1P4>##R1L6(-P\C_[&Q<4L;^J`@%.'#@@Z:&RS>?,&3D#88[32D?.&
MS=DD3J8D(5+D>W@0Z0>"R#TGNYPQH%V$`A7WC5=>>ENQYQX(R_E`&AQEW/4=
M60"Z(!P(!-HVT!AEI:$5"!_N9D<:[+G1QF[>E06"7?IIQ48>(+H!('39T6'5
M0`V")QYY<+C08(-3O'&B9V3`"$=N(V8WQXLQVJ<B>+F%008(<]1QQAG('3=E
M'5:Y@=X;^O'G'X!S6(<A&F%X9Q>,IS6X)G7>B6&;CB#(.8=WOL%(QQL@G%'=
M14.`:9N8=?R'W'!IL,$&"&BR1:60MO6VAF]RD)&96<@U&(99;W"89AE3IF&&
M?67`F)L99>0FHVUY=?;;'-"U-8:928R:!*-2.GG6D9VQX1H(M]Z1'1MD,%8;
MD\09-Z>P##)G7AED@CAJ?K:-P>6>;:2A!ZC?\4DG?Q".X9:C(I*HU8E;G85"
MA&.@T:"P=1"+JZ/&G?7&'6Y$%\:)*4#'G7<ZM@%"0""0(2JJJGHW1QEGH&LC
M=#KFFR:IW<+A*UN+OC$JG9K"8?%;:7J8[T#'R9%M9L.A\18:()1;HL/`SANI
M0-MU!\)=92"\&X#=4OP@>T>F\6FS/IB!F;@B#[P5GV'T.9X8OVWW1D`EFYEA
MOD$PP4258BP<1QTH[I=SJCL?NB?%1LOHUH?PRBMG@R,V#=[$<$R]5:K0435E
ML,-:6@9;<LA\LW0Z!HZ@P6OSMNB=G\*\Z1KGW>R9S6WDT:#+YZ+H(UT*))$O
M@4-`ET=V)TSY*I\&+OQHH3Q?K%;!98AA99TP<AGYPG#<-32U8O?'.G)F!N$&
MC'Z"B>L8:]S,'F93SDW'#]`OM]RMQLYY7]I(?U@WU:D./%`89F)71^E4NJ6H
MX'0PB[ONQX'`QEU8;I<&M(=JC)^@/=M%=1@!0<RT'5.;$D'6TS0Y8,8M)P(!
M]A*'G]^X9W/3L]5PR#:<XKC%2VAKSWC(@D'`6>5#]KO">?0`G2KE!CK&&4[?
MML,>J'D%1G*ZGQQR(RZKA:$V%$-@&:!#!CZE,#TSA!8=7@0=-5S+?;2Q30H7
MI@>E@:`)8>#0TN;`,M,PR3-O6$.9I*<`(=B,8)436]2$)0=B0><.93B!H_P$
M,#[Q:D]TR`.$[C<0'L9N=G0:2!NF$[$5W5")WC&@Q,YBADUY9U-2,TL:O&*;
M#S6-+&&B2OSL9Y=V!01X7+R"AK1R`N\TRC:[R<X96*9#$`5N#E0QCI'L9J/\
M\6\KKU3@:2;$I_5)IGT>%)F]IH4_,A0J<@4D31JF],8WQ-$\&,Q95@X2/!",
MB&='0LXPP^:;=-T,=GOLF2"1.,KCN"%RA;Q3DYJ6A"1PR)3`JA4>H".[0U+I
M-\BQ2[Z,*$XTG>5LGZ08*A-(J4,)\IL8=*34#A(&1M*R8),Y2QC,4#**60$*
MV.33+-6B.L:@"E'G`]"F0,/%(`T,3RN,X3=Y=C;]P9)@3W!"?7QG*&>FZH/Y
M(@MX0"`"40W$#"(H7^-0=,]:RK1=+.P4<OH3N(%`2"!A"PAC4+:IA;7AA1`+
MS^>N\(2@JD&(A)PEZ%*V,L$9S`PZV\K]VF`>7P6N/(F#U>":=Y_TD#51W:-B
M2&TS![]X)Y16(B6?L)296VHH9Y?LJ=BBN3"QUFNL92U#"TJ)5EU"4`%/X&6A
M%D8C."!06R'[T#+/-`05QFM*_5E+I-QG3&GIBITV(]S-,KK1+7*.0%31(@A:
MP,7<I6=S+<@M;3MW-SEDA@XZ2(!MWP"$S!1*2%0!$&KF`(<R[9$.+G#K<H+@
M,5\Q(2!K"*X3TH0F-\B`BTXHPW'GP*&R@<`$(!@"B:QU6"`\T9BG:4\8H..Y
M64WW6OW#$$$V!9TJ3"$(7$3!&%(0@QSD``;0@0(6G&"=*=1!#%<55\^@\&#&
MC`$$3.@-"`S<@AK```=F$H(*A!`"$,QE+DQ)L8I7S.(6N_C%,(ZQC&=,XQK;
M^,8XSK&.=\SC'OOXQT`.<HT#,I""0$7(+_9(1C;2$8^`Y"07*0F41Z(2EK@$
M)C*AB4TN@A.=\`3)8`ZSF,=,9H8X!2I2H8I5L**>KGPE+(4ABUG0HA:VN`4N
M<ND+_/0B`[[4!7Z`Z;-@P$(8PR#&#(UAC%0>PX7(3*8RE_GM9CKSF=",IC2G
M2<UJ6O.:V,P&A[C1#6]\`QSA).LXR6F0<Z`C'5;_"03BJQG`"L2CR"%H/>UY
M3WSF4Q\Z\8Y0AC+3@&A](/4HZ"P=@Y"$TO<6T%PH0[#C$$R;A#D3)?4L+&JD
M&YBDE1F!J#LW*D..B-VC'S$G2$,"DY&0Y"$N<3M?X'D2&J($6BMAZ4[<LAT&
M?XV<,0'O(K!5TV1,Z::!JS:&=+(3G@9^-C^9*5!AZO?OSD*6\^6S/PF4%*7\
MAJDY:(I3GM+2P#86'E.-354\:Q74W!,K.LSJ(K6*&9K8JB)>,5)@?/ML]9!E
MP67QJ4'/BI;]>&>M.PE)6]PZV[>0$ZYQ@=(-(WH93V/#+G<QIVU3RN=A[Y4O
MWO#+7S8+F!._&E:%,<QA:NWCQ.BT)XO][77VXQAS'F3AS(ZL+:DZF6WNH#*@
M5AMFM\JGWF2MO).;5^GW^5EYBC.T!BTP:51CFM-<M:CM]=9J4@5!UK;V8*^!
M3:RG(MNJ!$NGQ[-MKG`3FGWHQDJ\K35F6,\,X`1'%6.&QW!:09S(HL:XXSAN
M#I##8$%KM"++,>?OFN.BYS@K.M*9SCVH(X_J6-JZMR]J(+*#C1AJUR78V')W
M^`,VF8(WO#Z1)^M13-Y=LD,SYT'O!\I'(@Y+?S0&6KZATP3?=9Q?OD0M*I_I
M4TMED#M^Y3[P8QM!5S^\I!\E]4IT\$K^<S,`-$PM@P<$M!\'E`8)9'KY`A>*
MXEH1!'L4=&J14WH:="^1DTL@-"HBY"4D1"6%LD,?Y5GR8G,%=475<AHT!%T`
M]T<YI($RV$,S"$0[2$0@0$_>43TSR$1.!$52M"=4Q"CM`4/DH46/Y44IDB]A
M%"6+0D9F-$%JQ"JE=3;%=$PY6$>PDWT4HT=\E'EV@4,IM$V(%$Z'M"MOH$@&
M)5"0-"B2U$BC4DDJ<RF/I4D%PTF>%`;D(AUY]1U`B$ZH]$UQ)#54(U@F]8`$
MLUD!2"4#R#ZVH8)585J\XTO%(7S[(4S$Q!YP)$>1HTRGP8.:YTS-QD+2-!!B
M54VMU#1LJ$V8P4UHX$W@9$CCE$[G-$OE9`;K5"<VTS2HY"MU115'>$3VU#,`
M>!_[M'<X<Q;_%#D"53<$95"92`8)=3,,U3UT\E`1A4X4)1ZBLG?^AQ\1LC"/
MY5$IA'5U8ALC-2=\4HFQE%(KY6\N)0?3)E,L4U-F<%,YU7NN,75G,Q;&`52\
M0B9$!3M'18M9N%21@BE/981]1`549558)4N!LU5\UU7Y1':BYQUNE5AG95FZ
ME#?MUU9"HI)48AJ?58]48E<MHXBCU#-\E2I#<U.!I4T#R!])U4HI"5>+U8B-
MI14@"%F2!9`RV%C9H@=V!Y*<[e-mail]3CX1UQIS)JU4YPLEJ+`A<+TY2P
MY0:RM5O+,5RXI5O3TUN_%5S#55SBQ1[RI%PNP%S.94S1)23355UE<%UJJ5W<
M117?Q3GA-5[EM2KGE5[K50?M]5Y[HB#S!2PRLCE!@%]N`!U4L%]JY5\`QCD"
M1F`&AF`@H&`,!@(.!F%"-&$5]A88IF$<YF$@=A$B1F(FI@`H5F:^^9O`&9S"
1.9S$69S&>9S(F9S*N9S,"1$5
`
end










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Need Help reading Picture from PictFile to Window
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 151
Date: 9 Feb 91 02:16:59 GMT

I am unable to get a CPicture that was written to a CPictFile to be
displayed when I load the picture. The CPicture is NOT a resource, but
just a straight picture. The PictFile is OK because I can view it in
Canvas. I have a CPictDisplayWindow that is sent a PicHandle from a
CPictDisplayDoc. The instance variables of the thePicture are OK (at
least the bounds of the Picture are set to the correct size), but I
can't get the thing to appear in my scrolling window.
Here is my window class.

/* CPictDisplayWindow.h -- window class */
#define _H_CPictDisplayWindow

#include <CBureaucrat.h>
#include <CDirector.h>
#include <CPane.h>
#include <CPicture.h>
#include <CScrollPane.h>
#include <CWindow.h>

struct CPictDisplayWindow : CWindow {
    CPane            *itsMainPane;
    CBureaucrat        *itsGopher;
    CScrollPane        *mainScroll;
    CPicture        *itsPicture;
    /*----------*/
    void        IPictDisplayWindow    (CDirector    *aSupervisor);
    void        Activate    (void);
    void         DoCommand    (long        theCommand);
    void        SetPicture    (PicHandle    thePicHandle);
    PicHandle    GetPicture    (void);
};

/* CPictDisplayWindow.c -- window methods */
#include <Commands.h>
#include <Constants.h>
#include <Global.h>
#include <CDecorator.h>
#include <CDesktop.h>
#include <CError.h>
#include <CRadioGroup.h>
#include <CSizeBox.h>
#include <TBUtilities.h>

#include "CPictDisplayWindow.h"

/*### REQUIREMENTS FOR THE WINDOW RESOURCE
    you must create a WIND resource with the following resID number
        it should be a zoomDocProc window (close box, zoom box, scroll bars)
###*/
static int    kPictDisplayWindID = 20000;
                    /* number of pixels scrolled per click on scroll bar */
static int    kScrollPixels     = 10;

extern    CDecorator        *gDecorator;    /* Window dressing object    */
extern    CDesktop        *gDesktop;        /* The enclosure for all windows */
extern    CError            *gError;        /* The error handling object */
extern    CBureaucrat        *gGopher;        /* The current boss in the chain of
command */

/*----------*/
void    CPictDisplayWindow::IPictDisplayWindow    (CDirector    *aSupervisor)
{
    CView            *enclosure;
    CBureaucrat        *supervisor;
    CSizeBox        *aSizeBox;
    CRadioGroup        *aGroup;
    CScrollPane        *theScrollPane;
    CPicture        *thePicture;

    IWindow (kPictDisplayWindID, FALSE, gDesktop, aSupervisor);
    itsMainPane = NULL;
    itsGopher = aSupervisor;
    enclosure = this;
    supervisor = this;

    aSizeBox = new (CSizeBox);
    aSizeBox->ISizeBox (enclosure, supervisor);

    theScrollPane = new( CScrollPane );
    theScrollPane->IScrollPane(    this, aSupervisor,
                                0, 0, 0, 0,
                                sizELASTIC, sizELASTIC,
                                TRUE, TRUE, TRUE );

    theScrollPane->FitToEnclFrame( TRUE, TRUE );
    theScrollPane->SetSteps( kScrollPixels, kScrollPixels );

    thePicture = new( CPicture );
    thePicture->IPicture( theScrollPane, aSupervisor,
                            0, 0, 0, 0,
                            sizELASTIC, sizELASTIC );

    /* make the itsPicture the entire available space within the PlotWindow
*/
    thePicture->FitToEnclosure( TRUE, TRUE );
    theScrollPane->InstallPanorama( thePicture );

    mainScroll = theScrollPane;
    itsPicture = thePicture;
    itsMainPane = itsPicture;
    itsGopher = itsPicture;
} /* IPlotWindow */

/*----------*/
void CPictDisplayWindow::Activate        (void)
{
    inherited::Activate ();
    gGopher = itsGopher;
} /* Activate */

/*----------*/
void CPictDisplayWindow::DoCommand        (long        theCommand)
{
    switch (theCommand) {
        default:
                inherited::DoCommand (theCommand);
            break;
    } /* switch */

} /* DoCommand */

/*----------*/
void        CPictDisplayWindow::SetPicture    (PicHandle    thePicHandle)
{
    itsPicture->SetMacPicture( thePicHandle );
    if (mainScroll != NULL) {
        mainScroll->AdjustScrollMax();
    }
    itsMainPane->Prepare();
    itsMainPane->Refresh();
} /* SetPicture */

/*----------*/
PicHandle    CPictDisplayWindow::GetPicture    (void)
{
    return ( itsPicture->GetMacPicture() );
} /* GetPicture */

/* CPictDisplayWindow.c */


Any ideas? Thanks in advance.

Cheers,
David S. McCormick
MIT-EAPS Geology
Bldg. 54-1016
Cambridge, MA 02139
617-253-9852
[e-mail]
CompuServe: 71540,2765










Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  09-Feb-1991 0927")
Subject: re: getting a picture
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 9 Feb 91 15:25:01 GMT

dmc@eagle writes:
>I am unable to get a CPicture that was written to a CPictFile to be
>displayed when I load the picture. The CPicture is NOT a resource, but
...
     itsMainPane = itsPicture;

I wonder whether itsMainPane ought to be the CScrollPane that you created.

By the way, why didn't you write this as a CDocument class (then the
file would point to your PICT file)?  There may be some magic in CDocument
that you're not doing.  Have you poked around the PICT handle after it
was read in?  (It was read in, right?)

My gut feel about TCL (as of this instant), is that it's best to keep
visual classes (CWindow, CPane, etc) separate from data classes (CPicture),
linking them together with methods like InstallPanorama and the occassional
instance variable or instance list (like itsMainPane and itsSubViews).

Good luck.

Martin.










Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  09-Feb-1991 2039")
Subject: Another CPicture example
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 54
Date: 10 Feb 91 01:48:44 GMT

Here's an example (edited from newly-working code) that shows how
to create a Pict Panorama and load it from a file.

Martin Minow
[e-mail]

/*
 * Call this (first) to create a CPicture that fills itsMainPane.
 */
void
MyMainPane::CreatePicture()
{
    itsPicture = new(CPicture);
    itsPicture->IPicture(
        itsMainPane,
        this,
        0, 0, 0, 0,
        sizELASTIC,
        sizELASTIC
    );
     itsPicture->FitToEnclFrame(TRUE, TRUE);
    itsPicture->SetScaled(TRUE);
}

/*
 * Then call this to read the Picture from a specified file.
 */
void
MyApp::ReadPict(
    Str255    pictFileName
    )
{
    CPictFile    *aFile;
    OSErr        status;
    Handle        aHandle;

    aFile = new(CPictFile);
    aFile->IPictFile();
    aFile->Specify(pictFileName, 0);    /* Current directory    */
    status = aFile->Open(fsRdPerm);
    if (gError->CheckOSError(status)) {
        status = aFile->ReadAll(&aHandle);
        if (gError->CheckOSError(status)) {
        itsPictHandle = (PicHandle) aHandle;
        myDoc
            ->myMainPane
            ->itsPicture
            ->SetMacPicture(itsPictHandle);
        }
        status = aFile->Close();
        gError->CheckOSError(status);
    }
    aFile->Dispose();
}










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Last CPicture question: strange clipping of CPicture in ScrollPane
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 71
Date: 10 Feb 91 06:53:11 GMT

I create a Picture in my program in a ScrollPane and write it to a Pict
file just fine. I can open it in Canvas and everything is ducky. I read
the Picture back into a window dedicated solely to the display of
Pictures. The bounds of the Picture is correct and the ScrollPane into
which the Picture is installed works just fine. The problem is that the
Pict image is clipped such that part of the image cannot be seen, even
though I can scroll over the entire bounds of the picture. The visible
area corresponds to the clipped area of the original window in which it
was drawn just before it was saved to the PictFile. There is some
ClipRect that is not getting reset? Is the aperture of my Picture not
being reset? Is this information stored in the PictFile? What am I
missing here?

The following is the window initalization routine.

/*----------*/
void    CPictDisplayWindow::IPictDisplayWindow    (
    CDirector    *aSupervisor,
    PicHandle    thePicHandle)
{
    CView            *enclosure;
    CBureaucrat        *supervisor;
    CSizeBox        *aSizeBox;
    CRadioGroup        *aGroup;
    CScrollPane        *theScrollPane;
    CPicture        *thePicture;

    IWindow (kPictDisplayWindID, FALSE, gDesktop, aSupervisor);
    enclosure = this;
    supervisor = this;

    aSizeBox = new (CSizeBox);
    aSizeBox->ISizeBox (enclosure, supervisor);

    theScrollPane = new( CScrollPane );
    theScrollPane->IScrollPane(    this, aSupervisor,
                                0, 0, 0, 0,
                                sizELASTIC, sizELASTIC,
                                TRUE, TRUE, TRUE );

    theScrollPane->FitToEnclFrame( TRUE, TRUE );

    theScrollPane->SetSteps( kScrollSteps, kScrollSteps );

    thePicture = new( CPicture );
    thePicture->IPicture( theScrollPane, aSupervisor,
                            0, 0, 0, 0,
                            sizELASTIC, sizELASTIC );

    thePicture->FitToEnclosure( TRUE, TRUE );
    thePicture->SetMacPicture( thePicHandle );
    theScrollPane->InstallPanorama( thePicture );

    mainScroll = theScrollPane;
    itsPicture = thePicture;
    itsMainPane = itsPicture;
    itsGopher = itsPicture;

} /* IPlotWindow */


Thanks everyone.

Cheers,
David S. McCormick
MIT-EAPS Geology
Bldg. 54-1016
Cambridge, MA 02139
617-253-9852
[e-mail]
CompuServe: 71540,2765










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: 4+ version 1.4
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 31
Date: 11 Feb 91 01:28:47 GMT
Phone: [phone]

From: "David S. McCormick" <[e-mail]>
Date: Thu, 07 Feb 91 16:42:53
Subject: New version of 4Plus (v1.4) submitted to /incoming

I have uploaded a new version of 4Plus (v.1.4) to /incoming.
I have been using this version for 3 weeks on my SE/30 and have had no
problems; the author seems to have addressed many of the problems, and
even added some enhancements to the thing, like being able to access the
'vers' resources right from the menu. More importantly, this version
appears to coexist peacefully with Windows INIT which alters the menu
bar; I remember that lots of people claimed to have had problems with
programs which altered the menu bar. I did notice that DiskDoubler INIT,
which inserts itself into the menu bar, did disappear when 4Plus
inserted itself on launch of ThinkC. I has not crashed by system. The
only problem I have noticed is it's coexistence with CMarker CDEF, the
one which does function parsing and allows fast comment/uncomment. It
works flawlessly with the function parser, but sometimes causes and
"Think C unexpectedly quit: Out of application memory" error. Again,
CMarker's function parser still works flawlessly. As 4Plus has a
function parser, you don't really need both. My guess is that there
could be problems with Think C extensions which live in ThinkC's heap. I
know that Kiss 1.7 is totally preempted by 4Plus. The Browser facility,
editor extensions, GREP extensions, and macro facilities are really
great, though. Again lots of conflicts seem to have been ironed out.

Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]

[saved as: /mac/think-c/compiler/4plus-14.hqx; 136K]










Path: ucivax!gateway
From: [e-mail] (Wolfgang Naegeli)
Subject: Re: ARCHIVE- 4+ version 1.4
Message-ID: <[e-mail]>
Priority: Normal
Newsgroups: fa.think-c
Lines: 21
Date: 11 Feb 91 14:17:15 GMT

        Reply to:   RE>ARCHIVE: 4+ version 1.4
Mark Nagel writes:
> I did notice that DiskDoubler INIT, which inserts itself into the
> menu bar, did disappear when 4Plus inserted itself on launch of
> ThinkC. ...
The DD menu disappears regardless what application you launch, since it is only
active in the Finder.  Do you mean that after launching ThinkC with
4Plus, DD is gone when you switch back to the Finder?

> It works flawlessly with the function parser, but sometimes
> causes and "Think C unexpectedly quit: Out of application
> memory" error.
Have you tried giving ThinkC more RAM under MultiFinder?

Wolfgang N. Naegeli
University of Tennessee & Oak Ridge National Laboratory
Internet: [e-mail]    Bitnet: wnn@ornlstc
Phone: [phone]       Fax: [phone] (MacFax)
QuickMail (QM-QM): Wolfgang Naegeli @ 615-574-4510












Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Re: ARCHIVE- 4+ version 1.4
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 11 Feb 91 17:27:53 GMT

I submitted the 4Plus archive. You are absolutely correct that
DiskDoubler is only present in Finder; there are no problems with DD
reappearing my mistake. As to the memory problem, it seems to happen
regardless of partition size, but I haven't persued it exhaustively.
Hope this clears it up. The new version is much better.

Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: ListMgr Replacement class
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 11 Feb 91 19:22:56 GMT

               ListMgr Replacement class
I seem to remember a list manager replacement class floating by here sometime
in the past.  Unfortunately I seem to have accidently deleted my copy of it.
Could somebody please send me a copy?

Thanks-

Tom
[e-mail]












Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  11-Feb-1991 1436")
Subject: Proportionate scaling of CPictures
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 11 Feb 91 19:45:30 GMT

Now, I can read a picture and display it in a panorama.  But, my picture
is 3x5 inches and the window (CPanorama) it's going into is 4x7 inches
(numbers invented). If I SetScaled(TRUE), the picture is squashed so it
fills the window; if I SetScaled(FALSE), the picture is the right size
and shape, but stuck up against the top-left corner.  (or, if my picture's
dimensions are larger than the panorama, only part of it shows).  Scrolling
is not an option.

The right solution is to scale both axes so the picture fills the frame
without distortion.  Anyone have a code segment lying around that does
this (obviously, I don't quite understand the relation between "bounds"
and "frame").

Thanks.

Martin.

ps: Hello Symantec -- may we hope for lots of tiny examples in the
next version of the TCL manual?










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: CIdleChore.[hc] for sanity checks
Message-ID: <9102122159.AA08493@neuromancer>
Newsgroups: fa.think-c
Lines: 114
Date: 12 Feb 91 22:22:23 GMT

Hi Net,

I've been working on an idle time chore in TCL that performs sanity checking.  The code
below does NIL handle/pointer reference sniffing by looking at the zero location in memory
and maintaining a value that will trigger "odd address error" on 68000 class Macs and
"bus error" on 020/030/040 class Macs.  I've used it for a few years, kudos to my friends at
what used to be Caldera Software, but David Dunham just talked about similar techniques
in the Feb '91 MacTutor.

Here's my code.  It seems to work fine.  I'll bet it may give some grief to Microsoft wares,
which I tend to not to use.  Note that you've got to reset the zero loc value whenever the
application resumes from a switch or a DA.  Other wares, such as Control Panel's
"General" will tweek the same location.

Other "things" could be stuck in such a chore, eg. stack sniffing (although stack problems
happen deep in code, not in the event loop), fragmentation, etc.  I also use idle time
chores for updates to the screen that take more than 1/10 sec to calculate on a slow
machine, eg. celestial mechanics, etc., and for throwing occaisional animation surprises.

Does anybody have other types of idle time sanity checking they could share??
Thanks -

    paco.
----
Internet:        [e-mail]
AppleLink:        Nathan2
Voice Mail:        1.512.891.2973
CompuServe:        74020,2145

Neural Networks & Virtual Reality Development
CECT, Motorola, Inc., Austin, Texas, Gaia
(c)1991, PXN. Subject to Public Law 99-508.  B*B!



/********** snip, snip to: CIdleChore.h *********************************/
/****
 * CIdleChore.h
 *
 *    TCL Chore class for an idle time sanity checking.
 *
 *    Public Domain Software from Motorola, Inc.
 *    910208 Paco Xander Nathan
 *
 ****/

#define _H_CIdleChore
#include <CChore.h>

/*** Public Data Definitions
 ***/

#define BOZO_NONO    0xF0F0F1


struct CIdleChore : CChore {
    void    Perform(long *maxSleep);
};


/********** snip, snip to: CIdleChore.c *********************************/
/****
 * CIdleChore.c
 *
 *    TCL Chore methods for an idle time sanity checking.
 *
 *    Public Domain Software from Motorola, Inc.
 *    910208 Paco Xander Nathan
 *
 ****/

#include "CIdleChore.h"


/***
 * Perform -- OVERRIDE
 *
 ***/

void CIdleChore::Perform(long *maxSleep)
{
    register unsigned long    *zero;

    zero = NULL;

    if (*zero != BOZO_NONO) {
        gError->SevereMacError(memAdrErr);
        *zero = BOZO_NONO;
    }

    /* insert other fun tasks here ... */

    *maxSleep = 20L;
}


/********** snip, snip patches to: CYourApp.c *********************************/

/* somewhere in CYourApp::IYourApp() */

#include "CIdleChore.h"

    register unsigned long    *zero;

    *zero = NULL;
    zero = BOZO_NONO;
    AssignIdleChore(new(CIdleChore));

/* somewhere in CYourApp::Resume() */

    register unsigned long    *zero;

    *zero = NULL;
    zero = BOZO_NONO;










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: How do color icons get used?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 13 Feb 91 23:14:27 GMT

I have used ResEdit 2.1 to create the proper BNDL resource for a B&W,
icl4 and icl8 in the Bundle editor window and I have created a 'cicn'
for my application. The color icons don't show up on the 8bit system I'm
using under sys 6.0.5. How does one get the color icon to appear on the
color systems and the b&w one on monchrome ones?
Thanks,
Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: CIdleChore.[hc] for sanity checks
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 32
Date: 14 Feb 91 13:13:28 GMT

>/* somewhere in CYourApp::IYourApp() */
>
>#include "CIdleChore.h"
>
>    register unsigned long    *zero;
>
>    *zero = NULL;
>    zero = BOZO_NONO;
>    AssignIdleChore(new(CIdleChore));
>
>/* somewhere in CYourApp::Resume() */
>
>    register unsigned long    *zero;
>
>    *zero = NULL;
>    zero = BOZO_NONO;

This may be my imagination, but I think you have the `*' on the wrong line:
don't you want

        register unsigned long *zero = NULL;
        *zero = BOZO_NONO;

Also, I don't see why you bother to make it a register variable. But then,
I never use register variables anyway.

I ran a NilMinder VBL task for a while, but found that it causes crashes
with the TCL - perhaps the TCL uses the null location itself (or does its
own sanity checking).

Nick.











Path: ucivax!gateway
From: [e-mail] (Satoru Hataya)
Subject: include me in the mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 14 Feb 91 14:26:02 GMT


Please add me to the think-c mailing list.
                    Thanks,
                    satoru










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Answers to my questions about color icons
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 14 Feb 91 17:42:46 GMT

Thanks for all the rapid responses. The summary is as follows: no color
icons automatically until System 7.0.

" System 7.0 is the first version that
will do this [display color icons].  To do it in 6.0.*, you get an INIT
like ColorFinder, SunDesk, or Icon Colorizer (all are on Sumex), and put
your icon into the INIT file and reboot (or with IC, you just execute
the program, and it caches the icon -- it also works with other programs
that draw icons). "

Thanks one and all.
Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("local user(me")
Subject: ANSI libraries/stat call
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 14 Feb 91 19:30:59 GMT

I was recently trying to port a Unix program ('patch', actually)
to Think C, and discovered then that the Unix library doesn't emulate either
the 'stat' routine or the 'access' routine, both of which are extremely
 common in Unix programs. I realize that there are ways of doing these things
with Mac system calls, but if I wanted to rewrite the whole program I wouldn't
be using the ANSI/unix libraries anyway. Does anyone know of a more complete
set of emulated Unix calls for Think C?

Failing that, has anyone seen anything like Larry Wall's 'patch' program
for the Mac? For those who don't know, it reads difference files and
merges the differences in the original programs.

-- Brian
______________________________________________________
Brian Feinberg <[e-mail]>
UUCP:  oliveb!cirrusl!brian











Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: Re: CIdleChore.[hc] for sanity checks
Message-ID: <9102142024.AA09093@neuromancer>
Newsgroups: fa.think-c
Lines: 16
Date: 14 Feb 91 23:07:39 GMT

Yeh, I meant:

>This may be my imagination, but I think you have the `*' on the wrong line:
>don't you want
>
 >       unsigned long *zero = NULL;
 >       *zero = BOZO_NONO;

I mailed off a NeXT & somebody sat on my kybd before I finished.  Register variables were
purely because I ripped off code.  Looking forward to an optimizing compiler someday for
ThC, anyway!

I haven't found any TCL use of the NIL location.


paco.










Path: ucivax!gateway
From: [e-mail] (Brian Feinberg)
Subject: ANSI libraries/stat call
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 15 Feb 91 17:29:11 GMT

I was recently trying to port a Unix program ('patch', actually)
to Think C, and discovered then that the Unix library doesn't emulate either
the 'stat' routine or the 'access' routine, both of which are extremely
 common in Unix programs. I realize that there are ways of doing these things
with Mac system calls, but if I wanted to rewrite the whole program I wouldn't
be using the ANSI/unix libraries anyway. Does anyone know of a more complete
set of emulated Unix calls for Think C?

Failing that, has anyone seen anything like Larry Wall's 'patch' program
for the Mac? For those who don't know, it reads difference files and
merges the differences in the original programs.

-- Brian

______________________________________________________
Brian Feinberg <[e-mail]>
UUCP:  oliveb!cirrusl!brian











Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: gnuucp 4.3
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 54
Date: 15 Feb 91 18:12:53 GMT
Phone: [phone]

From:    "James E. O'Dell" <[e-mail]>
Date:    Thu, 14 Feb 91 22:35:09 EST
Subject: New Version of Mac/gnuucp

Mac/gnuucp from Fort Pond Research is a port of the GNU
version of the UUCP protocol to the Macintosh. In addition to the
UUCP transfer engine it also contains a HyperCard stack that is
used for both reading and sending mail to other users.

==========Mac/gnuucp 4.3 Features==========

Double Clickable documents that launch Mac/gnuucp
to automatically call the named host.

Each Mac/gnuucp has their own HyperCard stack for reading
and replying to mail.

Mac/gnuucp automatically forwards mail to a "Well
Connected Host"

Mac/gnuucp supports local mailing lists.

The mailreader has an indexing capability that presents
a summary of all messages in the current mail stack.

Mac/gnuucp has been verified to communicate with
Vax VMS gnuucp, SUN uucp, Quickmail, and ATT SVR3
uucp servers

Mail messages are sent with standard RFC822
mail headers and dates.

Mac/gnuucp works with all Hayes compatible
modems

==========================================

Registered users ($20) will be placed on the info-gnuucp
mailing list to be informed of updates, enhancements
as well as receiving communications regarding Mac/gnuucp
from other users.

As with all GNU programs source code is available and has been
distributed along with the binary form. If for any reason you want
the sources and cannot obtain them Fort Pond Research will supply
them for for a $20 copying fee.

Fort Pond Research
15 Fort Pond Road
Acton, MA 01720
[e-mail]

[saved as: /mac/think-c/appl/gnuucp-43.hqx; 312K]
[saved as: /mac/think-c/appl/gnuucp-43-source.hqx; 576K]










Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  15-Feb-1991 1430")
Subject: Printing (without a window)?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 15 Feb 91 20:50:05 GMT

My application is coming along nicely (after a few false starts), and
I'm about to add printing.  The problem is that I'm not printing anything
in a window -- my "report" exists only on paper.  The kicker is that
CPane's need an enclosure which, ultimately, is a window.

According to the TCL support folk, I should create an off-screen window,
create the printing Panes in that, and then use the normal printing
methods.

I'm wondering of someone has found a more elegant solution: i.e., a
CGrafPort class or some-such.

Grateful for any and all help.

Martin.
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Povl H. Pedersen")
Subject: Re: Patch for Think C (Was: ANSI libraries/stat call)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Vms-To: IN::"[e-mail]"
Lines: 8
Date: 15 Feb 91 22:52:38 GMT
X-Envelope-To: [e-mail]


There was some patch program in the 4.0 -> 4.02 upgrade package. It seems
to look very much like a normal patch file.

I guess we just need the documentation. Is SYMANTEC listening ?????

Povl H. Pedersen
[e-mail]   /   [e-mail]










Path: ucivax!gateway
From: bootsie![e-mail] ("Eric K. Olson")
Subject: Re: Patch for Think C
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 26
Date: 16 Feb 91 08:09:50 GMT

In your message of Feb 15, 10:52pm, you write:
> There was some patch program in the 4.0 -> 4.02 upgrade package. It seems
> to look very much like a normal patch file.

The Weaver program takes a control file and a bunch of diff files.  The
diff files are MPW Compare output, from version 1 or 2 of MPW.

The diffs are not context sensitive (meaning they have some chance of
working even if you modified the original code).  I always assumed
unix patch was context sensistive, but I may be wrong (never use it...).

Cheers!

-Eric







--
Eric K. Olson, Editor, Prepare()      NOTE:     [e-mail] doesn't work
Lexington Software Design             Internet: [e-mail]
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
[phone]                        Bitnet:   OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Patch for Think C
Message-ID: <[e-mail]>
In-Reply-To: Your message of 16 Feb 91 08:09:50 +0000.
             <[e-mail]>
Content-Type: text
Content-Length: 1125
Newsgroups: fa.think-c
Lines: 26
Date: 16 Feb 91 17:38:30 GMT


>In your message of Feb 15, 10:52pm, you write:
>The Weaver program takes a control file and a bunch of diff files.  The
>diff files are MPW Compare output, from version 1 or 2 of MPW.
>
>The diffs are not context sensitive (meaning they have some chance of
>working even if you modified the original code).  I always assumed
>unix patch was context sensistive, but I may be wrong (never use it...).

The Unix patch program is context sensitive, but very smart if you give
it the right type of input.

If you supply a context diff (usually 3 added lines of context around
the change), it will locate the area and apply the patch.  It will
search around the target area just in case you added or deleted lines
above that area.

If it can't find the area, it won't try.  The assumption is that if
the area has changed enough that the context doesn't match, it's
very likely that the changes made in that area will conflict with
the patch.  In general, I've found that I prefer this behavior to
having patch go ahead and jam in the change.

...David Elliott
[e-mail] | ...!{uunet,mips}!sonyusa!dce
...[phone]










Path: ucivax!gateway
From: [e-mail] (Brian Feinberg)
Subject: Patch program for Think C
Message-ID: <9102170426.AA12056@sunfire.>
Newsgroups: fa.think-c
Lines: 8
Date: 17 Feb 91 04:41:32 GMT

Since I was a bit unclear when I mentioned this before, I
should say that I meant I was trying to find a program to
apply Unix format patches to files. Since Autoweaver uses
its own file format, you can't use it to apply Unix diffs.
I'm just trying to apply some diffs I already have, and
would REALLY like to avoid either doing it by hand or
uploading everything to a Unix machine to patch, and then
downloading again.










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re:  Patch program for Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 17 Feb 91 05:37:36 GMT

AutoWeave uses files generated by the MPW Compare tool. It's a canonical format
so any diff program can be modified to emit this type of format.

R.










Path: ucivax!gateway
From: [e-mail]
Subject: Re: ARCHIVE: gnuucp 4.3
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 19
Date: 19 Feb 91 23:13:52 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0462047370> of Fri Feb 15 18:12:53 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 697
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.2-618034-ehorvath-197>
UA-Content-ID: <MAC-1.3.2-618034-ehorvath-197>
MTS-Message-ID: <ehorvath0502209060>

------------ Original Message -------------
From:    "James E. O'Dell" <[e-mail]>
Date:    Thu, 14 Feb 91 22:35:09 EST
Subject: New Version of Mac/gnuucp
...
[saved as: /mac/think-c/appl/gnuucp-43.hqx; 312K]
[saved as: /mac/think-c/appl/gnuucp-43-source.hqx; 576K]
--------- End of Original Message ---------

Please notice that the second package contains everything the first package
contains PLUS the source.  I wasted bandwidth (not to mention download time)
fetching both (mea culpa).

FYI, this release is quite an improvement over the previous (2.x) version.
Thanks to Jim O'Dell and his contributors for a job well done.

=Ned Horvath=
[e-mail]
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Jonathan Pace)
Subject: Re: ARCHIVE: gnuucp 4.3
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 20 Feb 91 03:17:12 GMT

   I'm new.  What is gnuucp?  Please post to the bboard - I'll read it.

Jon










Path: ucivax!gateway
From: [e-mail]
Subject: Re: what is gnuucp 4.3?
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 29
Date: 20 Feb 91 04:51:19 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0510345470> of Wed Feb 20 03:17:12 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 1435
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.2-618034-ehorvath-212>
UA-Content-ID: <MAC-1.3.2-618034-ehorvath-212>
MTS-Message-ID: <ehorvath0510436380>

> I'm new.  What is gnuucp?  Please post to the bboard - I'll read it.

Briefly: Mac/gnuucp is a Mac application, written in Think C 4.x, which allows
your Mac+Hayes-compatible modem to behave like a uucp node, at least insofar
as sending and receiving mail is concerned.  The program will initiate calls
to deliver mail, and/or wait for calls.  To the remote unix machine you're
just another unix box -- even though you're running under the MacOS, not A/UX.

The package includes a HyperCard stack that allows you to originate mail, and
which will read your incoming mail as well.  Several different people can have
"mail files" on the same Mac.  Outgoing mail is placed where the uucp-emulator
will find it.

There's also extensive documentation -- if you've ever had to administer the
older (pre-HoneyDanBER) uucp, there's not much new.  If that's a new
experience, try to find someone who's been there, or tough it out.  You do
need the collusion of the administrator on your mail feed, who must add your
Mac as a uucp node.

The gnu, of course, is suggestive of the Free Software Foundation, and gnuucp
is distributed with source if you want it.  If you don't plan to dig into the
source, or you just want to hack the hypercard scripts, you don't need the
source.

Mail is about the only thing fully supported at this time.  Future development
may include news readers or additional protocols.

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Christian E. Fritze")
Subject: TCL Dawdle() methods and sleep times
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 20 Feb 91 21:46:39 GMT

I have a Dawdle() method in a document which checks for certain conditions
when it is first called. Only if the conditions are TRUE are the guts of
the procedure entered, else the Dawdle() method returns immediately. If
the conditions are FALSE (and we bounce back out) I want the time until
this particular Dawdle() method is re-entered to be as short as possible.

The question is, how do I do this while giving enough time for other back-
ground tasks to perform necessary functions? Should I alter the maxSleep
parameter that is passed in? Change gSleepTime? Thanks for any help.



Christian E. Fritze                   |                            AOL:geneman
University of Chicago                 |               [e-mail]
Molecular Genetics and Cell Biology   |   "No one ever died of laughing" -M.B.
--










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ADMIN: About this list...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 80
Date: 21 Feb 91 03:18:18 GMT
Phone: [phone]

[NOTE: Most of you have already seen this at one time or another,
but because the list is distributed to local exploders, I can't be
sure all readers have seen it.  I'll be posting it once a month or
so from now on.  Feel free to ignore it if you are already familiar
with it - Mark]

        About... The Think C electronic mailing list
        --------------------------------------------

This list has been created to discuss topics of interest among users of
Symantec's Think C compiler for the Macintosh personal computer.  These
topics include:

    o programming tips and examples

    o discussion of compiler bugs and/or misfeatures and workarounds

    o questions related to programming the Macintosh with Think C and/or
      object-oriented programming

One request: if someone submits a question on something that seems simple to
you, please remember that it will seem simple to many of the other 300+
subscribers to the list.  Please reply to the sender directly unless you
feel it is warranted to broadcast the reply.  The person who submitted the
question is urged to followup at some time in the future with a summary of
responses, so others who might be interested can see what the solution was.
This simple rule will prevent much of the chaff that is present on many
mailing lists and newsgroups.

Archives of past discussions on the list are stored in the Think C Archive
(see below for access information) in the directory /mac/think-c/archives.

Requests for addition/deletion/address/questions changes should be sent to:

    [e-mail]

Submissions to the list should be sent to:

    [e-mail]

            About... The Think C Archive
            ----------------------------

An archive of submitted source code and other packages related to Think C is
available from ics.uci.edu via two transfer methods:

    o anonymous ftp to ics.uci.edu (128.195.1.1)

    o automated e-mail archive server on ics.uci.edu

The archive is stored in /mac/think-c for ftp.  To use the archive server,
send mail to:

    [e-mail]

Extensive help is available for this server by using a subject consisting of
the word "help."  For there, you should be able to determine how to navigate
the archive.

Submissions to the archive may be accomplished in one of two ways:

    o use anonymous ftp to drop the submission in /incoming on
      ics.uci.edu and send a note to think-c-request summarizing the
      submission.

    o use electronic mail to send the submission to think-c-request.

After the submission has been moved to the proper directory in the archive,
a notice will be sent to the list describing the new addition(s) to the
archive.  These notices will always have subject headers of the form
'ARCHIVE: xxx', where xxx is a brief description of the new addition.

WARNING: Items stored in the archive is not guaranteed in any way to have
been tested for functionality or absence of virii.  Retrieve and use at your
own risk.

Mark Nagel <[e-mail]>
Department of Information and Computer Science
University of California
Irvine, CA  92717










Path: ucivax!gateway
From: [e-mail] (Michael Kahn)
Subject: Deletion and Addition
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 21 Feb 91 15:04:26 GMT

Please delete:  [e-mail]
                [e-mail]
                [e-mail]
                [e-mail]
(I can't remember which address I used when I signed up)

Please add:     [e-mail]

This is a mail alias that will redistribute the think-c postings to
interested parties in our lab.

THanks,
Michael Kahn
([e-mail])










Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  21-Feb-1991 1052")
Subject: re: TCK Dawdle() methods and sleep times
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 21 Feb 91 17:02:04 GMT

According to rumor (someone told me this last night), set the
maxSleep to zero and you'll be re-entered.  In my case, Dawdle
dequeues a "work request" -- if it suceeds, I (plan to) set maxSleep
to zero so Dawdle is re-entered to dequeue another request.  This
is a better approach than looping on the dequeue operation as it
lets the rest of the event loop run each time.

Martin.
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: All you wanted to know about MIDI Manager
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 209
Date: 22 Feb 91 10:56:28 GMT

>Would someone (Nick...) like to expound upon the benefits of using Apple's
>MIDI Manager, what it is, what it does, and how one gets it?  I can't seem
to
>find mention of it in any of the Apple literature I have, nor is it listed
on
>Apple's confidential price list.

Well, I'll reply to the THINK C list as well as EMUSIC - it might be of
interest there as well.

What the hell, I'll fire this off to rec.music.synth and the Mac newsgroups
as well. That way, NOBODY will EVER have to ask about MIDI Manager again.
Right? Check...

Non-Mac people might find this interesting as an overview of how to do MIDI
cleanly in a hardware independent manner, and how to provide a clean
abstract interface to the system services required by a MIDI application
and MIDI working environment.

Well, how one gets it for a start. Via APDA, I believe. Actually, I managed
to find MIDI Manager 2.0 on an FTP site somewhere with the Lime notation
software.
Apple haven't publicised it because they're still tied up in a lawsuit with
Apple Corp., the Beatles' record company.

There are three releases: 1.1, 1.2 and 2.0. 1.1 was the initial release
(1.0 never made it out the door). 1.2 fixed the odd bug, but rendered MM
useable only on machines with 256K ROM's, so the Mac Plus was out. 2.0
presumably has extra features, but I don't have any documentation for it,
so I don't know about them. All I know is that it seems a lot more
efficient. MOTU's Performer under MM1.2 was pretty sluggish even on an
SE/30. Performer under MM2.0 is fine. I don't know if MM2.0 runs on a Plus
or not.

What is it? Well, the first MIDI routines for the Mac were the usual
read-a-byte write-a-byte kind of thing. Various buggy versions of Kirk
Austin's assembly code were floating around all over the place, and even
today there are still lots of roll-your-own MIDI driving routines
(HyperMIDI, MIT toolkit, and so on). These are Bad News. Let me explain
why.

[AN ASIDE: Macintoshes have two serial ports, which support RS424 (I think
- the balanced-pair hardware spec. anyway). These are identical (modulo
processor interrupt priority) and plenty fast enough to run at MIDI speeds;
after all, they take AppleTalk in their stride. You need some hardware to
generate MIDI from RS424; you have to convert voltages, nail one half of
the RS424 to ground, build the current loop, and opto-isolate the input. In
addition, the interface provides the 1MHz (usually) signal to clock the
UART, rather than having the Mac try to invent a suitable baud-rate. So, a
Mac can support two independent MIDI Ins and Outs for 32 channels each way
if you use the serial ports; if you want more than that, you can pull
tricks like using a multiplexing protocol - this is what MOTU do for their
MIDI Time Piece, using an otherwise undefined MIDI Status Byte to signify
cable number. So, a MIDI interface is just a box of cheap electronics. I
built a dual-port MIDI interface with bi-colour activity LED's for about
$20. If you don't want to do that, feel free to pay Opcode $200 for
something similar. I don't know of any incompatibilities of the sort you
can get with weird mutant MP401 clones on the PC.]

Anyway: why not roll your own MIDI routines?

        o Hardware dependency. Sure, your routines worked fine on the Mac
512K,
          but for some reason they can't handle the auto sleep routines on
          the Portable (ain't that right Marc?). 'Nuff said?

        o Software parsing of MIDI. It's a real hassle, especially if you
          want to do it right and not fall flat when faced with embedded
          realtime bytes. And if you want to read and convert MIDI Time
Code
          and yes run fast enough to handle full-speed SysEx dumps from
          samplers, then it gets to be a headache.

        o Hardware independence. MIDI is not always going to mean the two
          serial ports on the back of your Mac. There are now expansion
cards
          for the Mac that require to get MIDI feeds from Mac sequencers.
          And I don't see why everybody should extend their applications to
          handle those, or MOTU's MTP, or any new gizmo which comes along.
          In fact, a MIDI program shouldn't know or care whether it's
talking to
          a serial port, a plug-in card, another MIDI program, or itself;
the
          MIDI data transfers and timing functions should work regardless.
          Abstraction's a wonderful thing.

        o Asynchronous communication. Your wonderful ReadAByte/WriteAByte
          echo routine is going to sound rather silly if everything hangs
          for a few seconds when you change layers under MultiFinder or
open
          the Control Panel. MIDI communication should be running all the
time,
          in real time, and not be tied to the event loop. (I know. I've
done
          that. It's not pleasant.)

        o Software cooperation. I don't want my MIDI program to reprogram
the
          serial ports and shoot AppleTalk through the head. Nor should it
          interfere with other programs I'm running. In this age of
MultiFinder
          and true multitasking (shut up) a number of MIDI programs should,
if
          not actually communicate, then at least stay out of each others'
way.
          Of course, it would be ideal if programs could communicate with
each
          other. That way you can build MIDI systems out of smaller
components.

        o Timing functions. ReadAByte/WriteAByte MIDI routines are rather
          hopeless for tying a sequencer to MIDI Time Code coming in off
          a SMPTE-striped tape. Try it if you don't believe me.

So, MIDI Manager solves all these problems. It's an Apple product, which
means that (in theory) everyone has it and so every piece of software
should be using it. Just like the rest of the Toolbox. Why doesn't everyone
have it? Why haven't you even heard of it? Beats me. Ask the lawyers.

What do you get? There's a MIDI Manager INIT - this provides the traps for
the MIDI Manager, and a Sound Manager trap to say that MM is installed and
running. There's the Apple MIDI Driver - this is the link between the MIDI
Manager and the serial ports. The AMD will drive either or both ports at
one of three clock speeds (depending on your interface), and provides some
timecode services. Other vendors will provide alternative drivers for their
hardware (I'm eagerly awaiting MOTU's 8 x 8 MTP driver). And there's the
PatchBay, which lets users graphically connect applications to each other
and the ports. In fact, the PatchBay can be written using the MIDI Manager
traps - there's nothing magical about it. (Well, almost nothing.)

Suppose you want to write a MIDI Manager application. Well, when it starts
up,
it has to sign into the MIDI Manager (having verified that MM is
installed), and it has to sign out when it's finished. MIDI Manager loads
the port drivers when the first application signs in, and drops them when
the last application signs out.

When your application signs in it provides a name and an icon. This is what
PatchBay uses to display your application to the user.

To do anything useful, you have to create some communication ports and tell
MIDI Manager about them. There are three kinds:

        Input ports: these are created with hook routines which are called
        when MIDI data arrives for your application.

        Output ports: you use these to output MIDI data.

        Timing ports: these are tied to timebases (either internally
generated
        or externally linked) and provide timestamps for MIDI data.

You can have as many ports of whichever kind as you want. These are
presented in PatchBay; the user can then connect them together so that your
application ends up talking to serial ports, other applications, whatever.
Or, you can attach yourself to specific ports (which may still be awaiting
creation). There are interface guidelines for this.

The user can attach input and output ports in pairs using PatchBay; data
flows from output to input. In addition, data can be sent from one output
to several inputs, or from several outputs to one input (MIDI Manager does
the merging). The time ports allow applications to synchronise, so that a
master application (say, a timecode generator) can lock a slave application
(say, a sequencer). The Apple MIDI Driver provides time ports which read
real timecode from the outside world.

I won't go into the timing functions since they're rather complex. Input
and output is easier. Output is simple - to output a message, put it into a
buffer and send it. Long messages (SysEx's) are flagged with continuation
bits. Messages can be queued for future transmission using the time port
features; this is dead handy, since it means you can avoid SCC overruns by
staggering transmission timestamps. By being a little more clever, you can
do your own output buffering and have asynchronous service routines send
stuff out when required - see my example code for details. It's great to be
able to queue an entire SysEx bank dump for transmission over the next 30
seconds and then forget about it - the application happily keeps going,
responding to the user, regardless, as the data goes out under remote
control.

Input is asynchronous. You don't ask for the next message (well, you can,
but it's not cool). Instead, your read hook is called at interrupt time
when something arrives. You then get to deal with it then and there
regardless of what your application is doing otherwise, even if some other
application is frontmost under MultiFinder. Or, you can reject a message
and ask to see it again later when you're not busy. MIDI Echo is easy (the
readhook just sends the message out immediately); more complicated things
require work since the read hook isn't running in a first-class environment
- you don't have the usual access to globals, the ToolBox, and so on. But,
with a little thought, and a few semaphores, it's not too difficult. If you
have time ports, you can set up timer routines which you interface to much
like read hooks.

I don't think there's much more to say. I love MIDI Manager. It's nice to
see Performer and Anodyne (my MIDI generic editor/librarian) pass data to
each other and update their progress bargraphs in parallel. There are some
subtleties to do with giving each application access to its event loop
every now and then, but nothing difficult for your average Mac power
programmer. MIDI Manager tends to choke on extremely dense SysEx messages.
For example, I can capture a D-50 bank dump easily (it's a set of 200-odd
byte SysEx messages with timing gaps) but the VFX sends a single 65K
message which is a hassle. The problem is probably that my read hook is a
fairly ordinary C procedure. If I wanted top-notch performance I'd have to
assembly-code the thing.

Can't think of much more to say, really, apart from: APPLE: publicise and
distribute the damn thing, and everybody else: use it, dammit.

Nick.











Path: ucivax!gateway
From: [e-mail] ("James E. O'Dell")
Subject: Floating Point constants.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: "James E. O'Dell" <[e-mail]>
Organization: Fort Pond Research
Lines: 17
Date: 23 Feb 91 14:15:33 GMT

I need to know the actual sizes of the various floating point
numbers in THINK C. Unfortunately I don't have a SANE book
nearby.

When I look in the float.h documentation on page 7 of the THINK C
manual I notice that DBL_MANT_DIG and LDBL_MANT_DIG are the same.
Is this really true? Are DBL_DIG and LDBL_DIG also the same? I guess I would have assumed that long doubles would have more mantissa digits.

Also, I need to know the values of these constants
for short doubles.

Thanks for the help!
Jim O'Dell
Fort Pond Research
[e-mail]












Path: ucivax!gateway
From: [e-mail] (Jonathan Pace)
Subject: Simple Think C question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 24 Feb 91 06:07:25 GMT

   I'm working my way through the "Macintosh C Programming Primer" and I've
bombed on the Hello, World #2 program.  I get the error "invalid declaration"
when I precompile.  The offending line seems to be:

   WindowPtr   gHelloWindow;

I'm clueless.  Help, please.

Jon Pace










Path: ucivax!gateway
From: [e-mail]
Subject: Think C port of Disinfectant Sample code available
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 26 Feb 91 14:59:02 GMT


Each release of John Norstad's Disinfectant program is accompanied by
a release of Disinfectant's user interface code.  I've ported this
code to Think C 4.0.2 from MPW C.  The complete package is available
by anonymous ftp from think.com, in directory /public/disinfectant.

-r--r--r--  1 ephraim    989967 Feb 26 09:46 sample-2.4.sit.hqx

Please send bug reports to me, not John Norstad, as they're more
likely to be conversion problems than bugs in John's original code.

For MPW users, John's version of the package is available by anonymous
ftp from acns.nwu.edu, in directory /pub/disinfectant.










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Disinfectant interface code
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 29
Date: 27 Feb 91 19:35:52 GMT
Phone: [phone]

By request, I've added the THINK C port of the Disinfectant
interface source code to the archives.

Below is the original announcement for those of you who missed it.

Mark

/*****************************************************************************/

From: [e-mail]
Subject: Think C port of Disinfectant Sample code available
Date: 26 Feb 91 14:59:02 GMT

Each release of John Norstad's Disinfectant program is accompanied by
a release of Disinfectant's user interface code.  I've ported this
code to Think C 4.0.2 from MPW C.  The complete package is available
by anonymous ftp from think.com, in directory /public/disinfectant.

-r--r--r--  1 ephraim    989967 Feb 26 09:46 sample-2.4.sit.hqx

Please send bug reports to me, not John Norstad, as they're more
likely to be conversion problems than bugs in John's original code.

For MPW users, John's version of the package is available by anonymous
ftp from acns.nwu.edu, in directory /pub/disinfectant.

/*****************************************************************************/

[saved as: /mac/think-c/code/disinfectant-24.hqx; 976K]










Path: ucivax!gateway
From: [e-mail] (Garth Dickie)
Subject: class declarations
Message-ID: <9102272107.AA01278@macduffe>
Newsgroups: fa.think-c
Lines: 61
Date: 27 Feb 91 21:26:10 GMT

I am writing a class library for TC4; I want to experiment with some stuff
which doesn't fit into the TCL.  This question has to do with the way I create
objects from resource templates.

The idea is to correlate an integer with every class which may be instantiated
from a template.  Then that integer is translated at runtime into a void*,
which can be passed to new to get an object of the appropriate type.  What I
*don't* want to do is a switch with one line per class, or similar kludery.

Idealy, the template reader is a library routine which does not depend on the
actual classes being instantiated.  The current implementation is that the
integers are indexes into a table of void*, which is static, initialized
with the class names.  The source looks like:

-- for the table:

static void *classes[] = {
#include "classes.n"
}

-- for SARez, in the middle of a type definition,

decimal integer
#include "classes.n"
;

where "classes.n" is a comma-separated list of the class names.  The effect for
the table is to create an array of exactly the correct size, initialized with
void* values which may be passed to new in order to create an object.  The
effect for the Rez source is to create an enumerated integer field:  If in the
correct place it encounters the name of a class, it will output the index of
the class name in the classes.n file.  This is fine.

The trouble is, there must be a class declaration for *every class used* before
the table can be declared.  In practice, what this means is another file,
classes.h, which has a line '#include "class_name.h"' for each class.  Then
this file must be included before the table can be declared.

There are two big problems here:
 -- whenever a class header file is touched, the table is recompiled, which
    means reading every other header file, etc.

 -- I'm back to having two sets of values, classes.n and classes.h, which must
    be kept in sync.

Both of these situations ideally would be resolved by the linker.  That is, in
some contexts, class names are like function names.  If you pass one to new,
it is converted into a void*, and treated like a global extern, with the linker
resolving just what value to pass.  In effect, the declaration

struct base_class : indirect { a_method( void ); };

does two things:  It makes some kind of global entry that the linker resolves
which says 'base_class should resolve to a void*', and it makes an extern
declaration so that everything after that point knows about it.  What I would
like is a way to make this extern declaration without defining the value.  It
seems that there is some way for the linker to resolve this already -- there
is just no way to declare it.

Any ideas or help on this?
 -- garth










Path: ucivax!gateway
From: [e-mail] (Jamer)
Subject: subscription
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 28 Feb 91 19:18:03 GMT

Please subscribe me to this list.  I sent a request to listserv, but
apparently there isn't one.

Thanks.

Jamer Tittle
<[e-mail]>